home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d2 / uneedit.arc / RAMIT155.ARC / RAMIT.DOC < prev    next >
Text File  |  1988-12-17  |  30KB  |  946 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                          +-------------+
  8.                          |  RAMIT!!!   |
  9.                          +-------------+
  10.  
  11.  
  12.  
  13.      If you're  running an  8-bit hard disk controller (generally
  14.      designed for  both PCs and ATs) on a 16 bit machine (like an
  15.      AT or  AT&T PC6300)  then RAMIT!  may be  able to  help  you
  16.      improve your disk transfer speed.
  17.  
  18.  
  19.  
  20.  
  21.      What is RAMIT?
  22.                               RAMIT is  a program to run the disk
  23.                               code supplied  with an PC type disk
  24.                               controller out  of RAM  rather than
  25.                               from the disk controller's ROM.
  26.      
  27.      What does that do?
  28.                               By running  out of  RAM rather than
  29.                               ROM, some  machines can  achieve  a
  30.                               real  performance   gain  in   disk
  31.                               transfer time.
  32.      
  33.      Does this apply to
  34.      me?
  35.                               RAMIT can  make a  difference in  a
  36.                               number of  situations.   To see any
  37.                               disk performance improvement,
  38.                               
  39.                               1. You  must be  using a  hard disk
  40.                               controller which  has its  own BIOS
  41.                               ROM code.  This includes unmodified
  42.                               Western Digital,  Mountain, Perstor
  43.                               and  Plus  [Hardcard]  controllers.
  44.                               Undoubtedly there are many others.
  45.                               
  46.                               2. You  must have  a machine  which
  47.                               runs code  faster from RAM than the
  48.                               I/O bus.  This includes all 16 bits
  49.                               machines (AT  types) and many other
  50.                               compatibles (e.g. AT&T PC6300).
  51.                               
  52.                               3.  You must be willing to reformat
  53.                               your hard  disk to  get the benefit
  54.                               of this  speedup.   Naturally, this
  55.                               requires a full backup and restore.
  56.      
  57.      Still Interested?
  58.                               Read on.
  59.  
  60.  
  61.  
  62.  
  63.  
  64. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  65.  
  66.  
  67.  
  68.  
  69.  
  70.               +-----------------------------------+
  71.               |  OK, so what does RAMIT! do!!!!   |
  72.               +-----------------------------------+
  73.  
  74.  
  75. RAMIT! is a TSR which relocates your disk controller ROM into
  76. high-speed RAM and 'fixes up' MSDOS to run the disk code from
  77. RAM.
  78.  
  79. RAMIT! operates as follows:
  80.  
  81.      1. RAMIT!  verifies that  there  is  a  valid  ROM  BIOS  at
  82.      C800:0000.
  83.  
  84.      2. RAMIT! copies the disk ROM contents to RAM.
  85.  
  86.      3. RAMIT!  disassembles the  ROM to  find out  what  it  had
  87.      placed in vector locations 4C and 64.  These are the primary
  88.      entry points  into the  ROM code.   If  RAMIT! is  unable to
  89.      determine  these  values,  then  it  aborts  with  an  error
  90.      message.   This is  generally  attributable  to  an  unusual
  91.      instruction sequence  used to  'steal' the vectors.  Contact
  92.      the author for unusual ROMs.
  93.  
  94.      If you'd rather do the disassembly yourself, the original 4C
  95.      and 64  vector addresses  can be  specified on  the  command
  96.      line.   This is  the dirty  way to support controllers whose
  97.      initialization sequence  is simply  too messy  for automatic
  98.      decoding.
  99.  
  100.      4. RAMIT!  'fixes' MSDOS or PCDOS by finding where DOS keeps
  101.      the vector  originally placed  by  the  disk  ROM  BIOS  and
  102.      redirecting it to the RAM copy.
  103.  
  104.      5. RAMIT!  exits, leaving  only a  copy of  the vendor's ROM
  105.      code.   All RAMIT! code is removed.  Most unused ROM code is
  106.      also removed.   The  amount of  memory taken  depends on the
  107.      size and  complexity of the disk controller ROM BIOS.  In no
  108.      event will it be more than 8K of code.
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.                 +----------------------------+
  135.                 |  Well how do I run RAMIT?  |
  136.                 +----------------------------+
  137.  
  138.  
  139.  
  140.  
  141. Find out your current performance level
  142.  
  143.      Before seeing whether RAMIT! can make a difference, you must
  144.      know how your system performs before RAMIT! is installed.
  145.  
  146.      If your  disk/PC combination  is not explicitly mentioned in
  147.      the README.RAM  file in  this archive  (and you  can't  find
  148.      another PC close enough), then you may have to experiment to
  149.      find the best interleave factor.
  150.  
  151.      SPINTEST is a publicly available utility which computes disk
  152.      transfer rate.   It  can be  used to  see when  the  optimum
  153.      interleave has been established.
  154.  
  155.      Another program, ATDISK, often distributed as part of the PC
  156.      Tech Journal utilities will calculate the transfer rate.
  157.  
  158.      Finally, the  CORETEST program  from Core International will
  159.      compute the  transfer rate.   Any  of these  programs can be
  160.      used to  determine when  the  optimum  interleave  has  been
  161.      found.
  162.  
  163.      First, run SPINTEST to get the transfer rate and interleave.
  164.      Then  reduce   the  interleave  until  you  suddenly  see  a
  165.      reduction in  the transfer  rate.  At that point you've gone
  166.      too far!  Back off by increasing the interleave slightly and
  167.      reformat for the last time.
  168.  
  169.      MAKE SURE  THAT YOU'VE  INSTALLED RAMIT  BEFORE RUNNING  ANY
  170.      PERFORMANCE TEST.   IF YOU HAVEN'T YOU'RE JUST MEASURING THE
  171.      PLAIN  VANILLA  PERFORMANCE  OF  YOUR  CONTROLLER  ROM-BASED
  172.      SOFTWARE!!!
  173.  
  174.      The following may serve as an example:
  175.           Set IL=6; Spintest says 6 revolutions to read a track.
  176.           Set IL=5; Spintest says 5 revolutions to read a track.
  177.           Set IL=4; Spintest says 4 revolutions to read a track.
  178.           Set IL=3; Spintest says 18 revolutions to read a track.
  179.           
  180.           At this  point, going  to an  interleave of 3 does more
  181.           harm than good.  Back off and use an interleave of 4.
  182.  
  183.  
  184.  
  185. Testing RAMIT! the first time
  186.  
  187.  
  188.  
  189.  
  190. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  191.  
  192.  
  193.  
  194.  
  195.  
  196.      At first,  RAMIT! should  be run  in TEST  mode.   This will
  197.      indicate whether RAMIT! is likely to work on your machine.
  198.  
  199.      Type
  200.           
  201.           RAMIT /T
  202.  
  203.      and examine  the output.   There  should be  three  messages
  204.      indicating that  0000:xxxx  has  been  overwritten.    Don't
  205.      worry, in TEST mode the memory is not actually modified.
  206.  
  207.      If RAMIT!  fails or  the messages  don't appear,  check  the
  208.      README.RAM file in this archive.  If your drive and computer
  209.      isn't on  the list,  be careful.   Things  may very well not
  210.      work.
  211.  
  212.      If you  get no error messages, RAMIT! will probably work for
  213.      you.
  214.  
  215.      The following  is a sample installation using the /V option.
  216.      (Specifying /T assumes /V.)
  217.  
  218.           > RAMIT /E1 /V /4c:a79 /64:9a8
  219.           RAMIT!    [V1.4]  Copyright (c)  1987 Hanover  Systems.
  220.           All rights reserved.                   ]  Version
  221.           Editing segment reference at 06C0      ┐
  222.           Editing segment reference at 06EC      │
  223.           Editing segment reference at 0719      │
  224.           Editing segment reference at 0AD2      │
  225.           Editing segment reference at 0B59      │  From
  226.           Editing segment reference at 0BD4      │  Editing
  227.           Editing segment reference at 0CF4      │  C800
  228.           Editing segment reference at 0D55      │  Segment
  229.           Editing segment reference at 0E17      │  References
  230.           Editing segment reference at 0F19      │
  231.           Editing segment reference at 1128      │
  232.           Editing segment reference at 125E      ┘
  233.           Disk controller vector 1B at C800:0A79 moved to segment
  234.           0DB2
  235.           Overriding segment address at 0000:1ECB  ┐  Expect 2
  236.           Overriding segment address at 0000:2618  ┘  Messages
  237.           Disk controller vector 25 at C800:09A8 moved to segment
  238.           0DB2
  239.           Overriding segment address at 0000:261C  ] Expect 1 Msg
  240.           [OEM Disk BIOS]
  241.           
  242.  
  243.  
  244.  
  245.  
  246. Installing RAMIT!
  247.  
  248.      WARNING: BEFORE  INSTALLING RAMIT! MAKE SURE THAT YOU HAVE A
  249.      FULL  BACKUP  OF  YOUR  HARD  DISKS.    RAMIT!  CHANGES  THE
  250.  
  251.  
  252.  
  253. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  254.  
  255.  
  256.  
  257.  
  258.  
  259.      OPERATION OF  YOUR HARD  DISK CONTROLLER.   WHILE RAMIT! HAS
  260.      NOT CAUSED  ANY PROBLEMS  SO FAR, IT HASN'T BEEN RUN ON YOUR
  261.      MACHINE!!!!  TAKE PRECAUTIONS AND MAKE A BACKUP!!!!
  262.  
  263.      RAMIT! is installed for normal use by typing
  264.           
  265.           RAMIT
  266.  
  267.      You should  see two  messages: the  standard RAMIT!  version
  268.      header and  an identification  for the  disk controller  ROM
  269.      BIOS.
  270.  
  271.      Continue normal  operation with  RAMIT! for  a while.    You
  272.      should not  see any  performance change.    Just  make  sure
  273.      things are still working.
  274.  
  275.      RAMIT! should be placed in the AUTOEXEC.BAT file as near the
  276.      top as  possible.   The earlier  it's executed, the more the
  277.      AUTOEXEC.BAT programs  will  benefit  from  any  performance
  278.      improvement.
  279.  
  280.  
  281.  
  282.  
  283.  
  284. Tuning up your disk performance
  285.  
  286.      To see  a real  performance difference, you'll probably have
  287.      to reformat  your disk.   This  requires a low-level format,
  288.      not just a DOS format (i.e. the FORMAT command).
  289.  
  290.      For Western  Digital customers,  enter  DEBUG.    Old  cards
  291.      require that  AX be  set to the interleave.  On newer cards,
  292.      the ROM  code prompts  for the interleave.  Start the format
  293.      by typing 'G =C800:5'.
  294.  
  295.      OMTI customers can use the OMTIDISK utility.  As part of the
  296.      low-level format, you get to specify the interleave.
  297.  
  298.      Many other manufacturers use a similar scheme.  Refer to any
  299.      documentation  from  the  disk  controller  manufacturer  to
  300.      figure how to perform a low-level format.
  301.  
  302.      Keep  lowering   the  interleave,   formatting  and  running
  303.      SPINTEST until performance suddenly gets worse.  Then do one
  304.      more format at the best interleave obtained.
  305.  
  306.      If you've got a unique computer/controller situation, please
  307.      drop me  a line  on how  it went.   I'll  include it  in the
  308.      README.RAM file  so the next guy doesn't have to do all this
  309.      work over again.
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324. RAMIT! Command Format
  325.  
  326.      The syntax for RAMIT! is
  327.           
  328.           RAMIT  [/T]  [/V]  [/Ex]  [/Wfilename]
  329.                  [/4C:offset]  [/64:offset]
  330.  
  331.      where
  332.           
  333.           /E1  Specifies EDIT-1  mode.   In EDIT-1 mode, any C800
  334.                constant value within the ROM area will be changed
  335.                to the  segment where the ROM code gets relocated.
  336.                Some controllers examine their own CS to determine
  337.                whether  they're   strapped  for  the  primary  or
  338.                secondary addresses.  For example, the OMTI BIOS-7
  339.                (Universal) constantly checks its CS with C800.
  340.           
  341.           /E2  Specifies  EDIT-2   mode.      In   EDIT-2   mode,
  342.                instructions  matching  either  of  the  following
  343.                patterns  are  changed  to  reflect  the  new  RAM
  344.                segment:
  345.           
  346.                     CMP   byte reg,0C8h   or    POP   AX/BX/CX/DX
  347.                     JE or JNE                   CMP   xH,0C8h
  348.           
  349.                This is required for the WD Super BIOS.
  350.           
  351.           /V   Specifies VERBOSE  mode.   In VERBOSE mode, RAMIT!
  352.                will  print   additional  status  messages  as  it
  353.                analyzes and  installs  the  disk  controller  ROM
  354.                BIOS.
  355.           
  356.           /T   Specifies TEST  mode.   In TEST  mode, RAMIT! will
  357.                perform its analysis BUT WILL NOT MAKE ANY CHANGES
  358.                TO DOS,  OR INSTALL  A RAM  COPY OF  THE ROM BIOS.
  359.                TEST mode  is  provided  so  that  RAMIT!  can  be
  360.                checked on  new controllers  or versions  of  DOS.
  361.                TEST mode forces VERBOSE mode.
  362.           
  363.                A successful  TEST will produce no error messages,
  364.                and identify THREE overwritten locations;  two for
  365.                vector 1B and another for vector 25.
  366.           
  367.                If this  is not  the case,  RAMIT  may  not  work.
  368.                Contact the author for more instructions.
  369.           
  370.           /W   Indicates that  the disk controller ROM BIOS is to
  371.                be  written  out  to  the  file  specified.    The
  372.                'filename' immediately follows the /W; for example
  373.                '/WDISK.ROM'.
  374.           
  375.  
  376.  
  377.  
  378.  
  379. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  380.  
  381.  
  382.  
  383.  
  384.  
  385.                This feature is provided so RAMIT! can capture new
  386.                or  updated   disk  controller   ROMs  for  future
  387.                support.     If  you   have  a  non-standard  disk
  388.                controller, and  it won't install with RAMIT!, use
  389.                the /W  option to  make a disk copy and send it to
  390.                me.   I'll try  to extend  RAMIT!  for  your  disk
  391.                controller.
  392.           
  393.           /4C: Explicitly  specifies an offset which the BIOS had
  394.                stuffed into  vector location  4C.    Rather  than
  395.                disassembling the  ROM code,  this  value  can  be
  396.                specified on the command line.
  397.           
  398.           /64: Explicitly  specifies an offset which the BIOS had
  399.                stuffed into  vector location  64.    Rather  than
  400.                disassembling the  ROM code,  this  value  can  be
  401.                specified on the command line.
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  443.  
  444.  
  445.  
  446.  
  447.  
  448.          +---------------------------------------------------+
  449.          | A Quick Tutorial on hard disk controller software |
  450.          +---------------------------------------------------+
  451.  
  452. Getting started.
  453.  
  454.      When your  computer is  started, on-board  software in  Read
  455.      Only Memory (ROM) is started.  This software, called the ROM
  456.      BIOS, performs  a cursory  check of  the  machine  and  then
  457.      initializes all  the devices  it knows about (CRT, keyboard,
  458.      floppy etc).
  459.  
  460.      If you  have the  manufacturer's hard disk controller or the
  461.      manufacturer can  support the third party controller in your
  462.      machine, the ROM BIOS will take control of it.  If, however,
  463.      you're using  another board,  the original  ROM BIOS doesn't
  464.      know how to handle it.
  465.  
  466.      So that  you computer doesn't just stare at you, not knowing
  467.      how to  boot from  your hard  disk, IBM  set up  a procedure
  468.      whereby anybody  could gain  control automatically  from the
  469.      ROM BIOS and provide their own hard disk software.
  470.  
  471.      To quote from the IBM Technical Reference,
  472.           
  473.           "The ROM  BIOS provides a facility to integrate adapter
  474.           cards with  on-board ROM  code into the system.  During
  475.           POST  [Power  On  Self  Test],  interrupt  vectors  are
  476.           established for  the BIOS  calls.   After  the  default
  477.           vectors are in place, a scan for additional ROM modules
  478.           takes place.   At  this point,  a ROM  routine  on  the
  479.           adapter  card   may  gain  control    The  routine  may
  480.           establish or  intercept vectors to hook themselves into
  481.           the system.
  482.           
  483.           "The absolute addresses hex C8000 through hex F4000 are
  484.           scanned in  2K blocks in search of a valid adapter card
  485.           ROM.  A valid ROM is defined as follows:
  486.           
  487.           "Byte 0: Hex 55.
  488.           "Byte 1: Hex AA.
  489.           "Byte 2:  A length indicator representing the number of
  490.           512-byte blocks in the ROM (length/512).   ...
  491.           
  492.           "When the  POST identifies  a valid  ROM, it does a far
  493.           call to  byte 3  of the ROM (which should be executable
  494.           code).   The adapter  card may now perform its power-on
  495.           initialization tasks.   The  feature ROM  should return
  496.           control to the BIOS routines by executing a far return.
  497.  
  498.      All of  the cards  supported by RAMIT! use this technique to
  499.      initialize the  disk drive  itself, and  'steal' vectors  in
  500.      order to gain control when a disk command is required.
  501.  
  502.  
  503.  
  504.  
  505. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513. Doing Disk I/O.
  514.  
  515.      When DOS  or a program want to do disk I/O, it loads up some
  516.      registers with  the I/O parameters and executes an 'INT 13h'
  517.      instruction.  The CPU ends up calling whatever routine whose
  518.      address is in memory for 'vector 13'.
  519.  
  520.      At  power-on  time,  the  ROM  BIOS  puts  its  floppy  disk
  521.      handler's address in this memory location.
  522.  
  523.      If external  ROM  code  on  the  disk  controller  board  is
  524.      present, at  initialization time  it will  copy the  default
  525.      (ROM BIOS)  address to a private location (normally location
  526.      100h) and  supply its  own  address  for  vector  13.    The
  527.      controller's ROM  will then  receive control  after the 'INT
  528.      13h' instruction.   It will examine the parameters passed in
  529.      the registers.   If  the request  is not intended for one of
  530.      its disks,  then the  controller  ROM  code  will  pass  the
  531.      request along  to whatever  address it  found for  vector 13
  532.      originally.  This would normally be the ROM BIOS floppy disk
  533.      handler.
  534.  
  535.      In this way, the disk controller's ROM code gets a chance to
  536.      process every  disk I/O request.  This provides a simple way
  537.      for anyone  to make  a disk controller which works in nearly
  538.      all PC-compatibles.
  539.  
  540.      Of course,  there's no  reason why  the hard disk controller
  541.      would be  the only piece of code to take over the vector 13!
  542.      In fact,  MSDOS and  PCDOS both  do this  regularly.    They
  543.      provide a  handler to  scan all  disk I/O  for errors.   The
  544.      message
  545.           
  546.           I/O Error
  547.           Abort, Retry or Ignore?
  548.  
  549.      is a  DOS error trapped in this way.  Other programs such as
  550.      disk  caches   will  also   trap  this  vector.    The  only
  551.      requirement is  that  each  intercepting  program  which  is
  552.      unable to service a request fully must pass it along via the
  553.      vector 13 handler which was in place before the intercepting
  554.      program took over.
  555.  
  556.      This all seems very logical and is, in fact, a very powerful
  557.      mechanism  to  handle  disk  I/O  in  a  device  independent
  558.      fashion.
  559.  
  560.  
  561.  
  562.  
  563.  
  564. Ok, then where's the problem?
  565.  
  566.  
  567.  
  568. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  569.  
  570.  
  571.  
  572.  
  573.  
  574. -----------------------------
  575.  
  576. The speed difference between system RAM and PC-bus ROM.
  577.  
  578.      The code  which resides on the disk controller card is 'out'
  579.      on the  PC bus.   It is as 'reachable' and executable as any
  580.      code on in RAM or on the mother-board ROMs (where the system
  581.      ROM BIOS lives).
  582.  
  583.      For a  16 bit  machine,  there  is  an  enormous  difference
  584.      between on-board  RAM/ROM and  PC bus ROM:  each instruction
  585.      fetched from  the on-board RAM/ROM is read in a 16 bit chunk
  586.      at the  machine's maximum  speed.   Each instruction fetched
  587.      from the  PC bus  is  fetched  in  two  separate  operations
  588.      because the PC bus is only 8 bits wide.  In addition, the PC
  589.      bus often operates at one half the speed of the main memory,
  590.      or less.  Consequently, it can take anywhere from two to ten
  591.      times as  long to execute code based on the PC bus as on the
  592.      mother-board.
  593.  
  594.      For example,  suppose you have a Western Digital PC (not AT)
  595.      controller on  an AT type clone running at 12 Mhz.  First, a
  596.      16 bit  instruction fetch  must be  converted into two 8 bit
  597.      PC-bus fetches.   This  automatically doubles  any  request.
  598.      Next, our clone manufacturer tried to be very compatible, so
  599.      his PC-bus runs at 6MHz, just like the original IBM AT.  Add
  600.      in a  few wait  states and we will end up taking three times
  601.      as long to execute a simple instruction from PC-bus ROM than
  602.      from mother-board ROM or RAM.
  603.  
  604.  
  605.  
  606. So what if it's slower, the disk is slower still?
  607. -------------------------------------------------
  608.  
  609.      Up to  a point  this is  true.   Unfortunately, if  the disk
  610.      controller software  cannot get  commands out to the disk in
  611.      time, it  may miss  a whole  revolution.  At that point your
  612.      computer is  quite useless,  waiting for  the disk  to  come
  613.      around again.   The  proper spacing  of data  around a  disk
  614.      track is  determined by the disk 'interleave'.  If you don't
  615.      know what interleaving is or why it's so important, read the
  616.      next section.
  617.  
  618.      The best  interleave is  determined by the raw transfer rate
  619.      of the  machine and its hardware.  You can move data only so
  620.      fast from  disk to  memory.   It is  also determined  by the
  621.      speed  of   the  controlling  software  which  controls  the
  622.      hardware.   If you can speed the disk controller's software,
  623.      you won't  need as  much  time  to  execute  those  critical
  624.      functions and  you  may  be  able  to  run  with  a  smaller
  625.      interleave.
  626.  
  627.  
  628.  
  629.  
  630.  
  631. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  632.  
  633.  
  634.  
  635.  
  636.  
  637.      By way  of example,  I have  a AT&T  PC6300.  The 'generous'
  638.      retailer who  formatted my  disk used  the wrong interleave.
  639.      Consequently, it  took 18  revolutions to  read  a  mere  17
  640.      sectors from  my hard  disk!!   After reading  one sector, I
  641.      wasn't getting  ready to  read the next in time, so I had to
  642.      wait a  whole revolution!.   (PS.  there are  17 sectors per
  643.      track  on   most  hard  disks;  26  per  track  for  an  RLL
  644.      controller.)
  645.  
  646.      Thanks to  a program  by Steve Gibson, SPINTEST, I found the
  647.      ideal interleave  was 6.  After reformatting my disk, it now
  648.      took 'only'  6 revolutions  to read  a track,  a three  fold
  649.      improvement which  was immediately  noticeable when  loading
  650.      large programs.
  651.  
  652.      Trying any interleave lower ('better') than 6 put me back to
  653.      17 or 18 revolutions to read a track.
  654.  
  655.      When I  ran the  Western Digital  controller code from high-
  656.      speed RAM  rather than  the slow-speed PC bus, I was able to
  657.      use an  interleave of 4.  This allowed a track to be read in
  658.      only 4  revolutions.  Without any additional hardware, I was
  659.      able to  read raw  data 50%  faster just by running from RAM
  660.      over ROM.
  661.  
  662.      With the  OMTI RLL  (5527) controller,  I was able to reduce
  663.      the interleave from 6 to 3 on my AT&T machine.
  664.  
  665.      The only trick was getting my machine to run from RAM rather
  666.      than ROM.  That's what RAMIT! does.
  667.  
  668.  
  669.  
  670. Great!  Give me an example!
  671. ---------------------------
  672.  
  673.      For WD  controllers (with  the simple BIOS), leaving the ROM
  674.      BIOS chip in, and W3 still strapped, I would use:
  675.           
  676.           RAMIT
  677.  
  678.      This figures  everything out for itself and installs the ROM
  679.      BIOS into RAM.
  680.  
  681.      
  682.  
  683.      For the  OMTI 5527 RLL controller with the universal BIOS, I
  684.      use
  685.           
  686.           RAMIT  /E1  /4c:a79  /64:9a8
  687.  
  688.      The /E1  (edit) converts C800 constants to whatever-segment-
  689.      the-ROM-has-been-copied-to;   the /4c:  and  /64:  give  the
  690.  
  691.  
  692.  
  693.  
  694. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  695.  
  696.  
  697.  
  698.  
  699.  
  700.      original offsets  that  the  BIOS  had  stuffed  into  those
  701.      respective vectors.
  702.  
  703.      
  704.  
  705.      For the WD controller with the Super Bios, I use
  706.           
  707.           RAMIT  /E2  /4c:31a  /64:26d
  708.  
  709.      The /E2  (edit) converts  the  tests  for  segment  C800  to
  710.      whatever-segment-the-ROM-has-been-copied-to;   the /4c:  and
  711.      /64: give  the original  offsets that  the BIOS  had stuffed
  712.      into the respective vectors.
  713.  
  714.      Alas, the  WD RLL  controller is much more efficient because
  715.      it has  a much  larger  on-board  buffer.    This  evidently
  716.      reduces  the   CPU  interaction   and  thereby  lessens  the
  717.      opportunity  to  improve  the  controller's  performance  by
  718.      running from RAM.
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  758.  
  759.  
  760.  
  761.  
  762.  
  763.            +-----------------------------------------+
  764.            |  A quick tutorial on disk interleaving  |
  765.            +-----------------------------------------+
  766.  
  767.  
  768. What is interleaving?
  769.  
  770.      Interleaving is  the  technique  where  consecutive  logical
  771.      sectors are places several physical sectors apart around the
  772.      track.   The interleave  factor is  the  number  of  sectors
  773.      between consecutive  logical sectors.   For  example,  a  10
  774.      sector track  with an  interleave of  1  would  arrange  its
  775.      sectors
  776.           
  777.           1,2,3,4,5,6,7,8,9,10
  778.  
  779.      while one with an interleave of 3 would be arranged
  780.           
  781.           1,8,5,2,9,6,3,10,7,4
  782.  
  783.  
  784. Why bother interleaving?
  785.  
  786.      Controllers interleave  because they cannot transfer data to
  787.      memory as  fast as  they can  read it  off the  disk.   Some
  788.      controllers won't  transfer anything  unless the error check
  789.      codes are correct which cannot be determined until after the
  790.      entire sector is read.
  791.  
  792.      If the  sectors were  placed sequentially  on disk,    after
  793.      reading one sector, there  would   not  be  enough  time  to
  794.      transfer it  before the  next one  came along under the read
  795.      heads.   (Obviously, the  disk isn't  going to stop spinning
  796.      just because  the  controller  isn't  ready.)    By  putting
  797.      sequential sectors  the proper  distance apart,  the desired
  798.      sector is just about to be read when the controller is ready
  799.      to process it.
  800.  
  801. What is wrong with having the wrong interleave?
  802.  
  803.      With the  proper interleave,  after reading and transferring
  804.      sector 'n',  sector 'n+1'  is just about to come by.  If the
  805.      interleave is  too large,  we'll have  to skip over at least
  806.      one sector  which is  not 'n+1'.   This  will waste whatever
  807.      time it  takes to  skip over that sector.  If the interleave
  808.      is too  small, we've  already missed  sector 'n+1'.  We must
  809.      wait a  whole revolution  of the  disk before we get another
  810.      shot at  it.  If we were to read all 17 sectors (on a normal
  811.      disk), we'd require 17 revolutions.
  812.  
  813.  
  814. What should the PC6300 interleave be?
  815.  
  816.  
  817.  
  818.  
  819.  
  820. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  821.  
  822.  
  823.  
  824.  
  825.  
  826.      If you  have the  standard  [MFM]  WD  disk  controller,  an
  827.      interleave of 6 works best.  This is readily verified with a
  828.      number of public domain disk test programs.
  829.  
  830.      An interleave of 6 requires 6 revolutions to read one track.
  831.  
  832.      If you  have the  OMTI RLL  controller, an  interleave of  4
  833.      works best.
  834.  
  835.  
  836.  
  837. What should an AT interleave be?
  838.  
  839.      If you  have the  standard WD disk controller, an interleave
  840.      of 3  works best.   This  is the  standard low-level  format
  841.      value.
  842.  
  843.  
  844. How do I change my interleave?
  845.  
  846.      Unfortunately, the  only way  to change this [at the moment]
  847.      is  to   perform  a   low-level  reformat   of  your   disk.
  848.      Instructions vary  according to  manufacturer.    For  many,
  849.      enter  debug   and  jump   to  location  C800:0005.    After
  850.      performing a  low-level format,  a  regular  DOS  format  is
  851.      required.
  852.  
  853.  
  854.  
  855. How do I know how my interleave works?
  856.  
  857.      An excellent utility available at bulletin boards across the
  858.      country is  SPINTEST.   This program  was written  by  Steve
  859.      Gibson and reports how many revolutions are required to read
  860.      a track.   Some experimentation is required to determine the
  861.      optimal interleave  value.   As I  get reports for different
  862.      controller/computer  combinations,  I'll  put  them  in  the
  863.      associated README.RAM file.
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988
  884.  
  885.  
  886.  
  887.  
  888.  
  889. How is RAMIT! distributed!
  890.  
  891. RAMIT! is still in the development stages as I add support for
  892. more controllers.  Refer to the attached README.RAM file for the
  893. latest list.  RAMIT! may be distributed free of charge.  RAMIT!
  894. remains the copyrighted product of Hanover Systems, Newtown CT.
  895.  
  896. Before sleeping with full confidence, I'd make regular backups
  897. for the first few days.  I've never seen your machine or disk and
  898. therefore can't guarantee anything.  I have tested RAMIT! on
  899. every machine I have available to me.
  900.  
  901.  
  902.  
  903.  
  904.  
  905. Further inquiries may be directed to the author
  906.  
  907.            Christopher Smith
  908.            Hanover Systems
  909.            19 Tunnell Road
  910.            Newtown, CT. 06470-1242
  911.  
  912.            (203) 426-0024
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946. RAMIT!                  Copyright (c) Hanover Systems, 1987, 1988